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Abstract 

Object-oriented scripting languages such as JavaScript or Python gain in 
popularity due to their flexibility. Still, the growing code bases written in the 
languages call for methods that make possible to automatically control the 
properties of the programs that ensure their stability in the running time. We 
propose a type system, called Lucretia, that makes possible to control the ob- 
ject structure of languages with reflection. Subject reduction and soundness 
of the type system with respect to the semantics of the language is proved. 

1 Introduction 

Scripting object-oriented languages such as JavaScript, Python, Perl or Ruby be- 
came very popular [Sofl2] due to their succinctness of program expressions and 
flexibility of idioms MWNV09L These languages optimise the programmer time, 
rather than the machine time and are very effective when small programs are con- 
structed [PreOOl |WEF + 09l . The advantages of the languages that help when a 
short programs are developed can be detrimental in case big applications are cre- 
ated. Short code that has clear advantages when small programs are constructed 
MOus981 can provide less information for a person that looks for clues on what 
particualr piece of code is doing (and this is one of the most frequent activities 

*See|http : / /www . youtube . com/ watch?v=IuezNswtRf o 
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during software maintenance tasks, see e.g. [Sas96, KM CA06ID . Moreover, the 
strong invariants a programmer can rely on in case of statically typed languages 
are no longer valid as type of a particular value can change with each instruction 
and mostly in an uncontrolled way with each function call in the program. 

Still, systems that handle complex and critical tasks such as Swedish premium 
pension system [SteOl ] are deployed and continuously maintained. Therefore, it 
is desirable to study methods which help programmers in understanding their code 
and keeping it consistent. Therefore we propose a type system that handles dy- 
namic features of scripting languages and can help in understanding of the existing 
code. 

The type system we propose is presented in the style where many type annota- 
tions must be present to guarantee correct typechecking. In particular, we require 
that function declarations as well as labelled instructions are decorated with their 
types. What is more, the type system is so strong that the reconstruction of the 
types is (most probably) undecidable. However, the system is designed in such a 
way that it will primarily be used on top of a type inference algorithm and admits 
a wide range of type inference heuristics that are not complete, but provide cor- 
rect type annotations for wide range of programs. In addition, we would like to 
encourage programmers to add type annotations to their programs since the anno- 
tations can serve as an important documentation of the code invariants assumed by 
developers in the program construction phase. 

The inherent feature of the scripting languages is that a running time type of 
a particular variable may change in the course of program execution. This prob- 
lem can be solved to some extent through introduction of single assignment form 
for local variables. Still, this cannot be applied to object fields. The natural se- 
mantics of programs is such that the fields change and the efforts to circumvent 
this principle will most probably result in a complicated solution. Therefore, the 
statement that statically describes evolution of the running time type of a variable 
cannot be just a type name, but must reflect the journey of the running time type 
throughout the control flow graf of the program. It would be very inconvenient to 
repeat the structure of the whole control flow graf at each variable in the program. 
Therefore, it makes more sense to describe the type of each visible variable at each 
statically available program point. This is the approach we follow in this paper and 
present a type system which is inspired by the works on type-and-effect systems 
[MM09, GL86]. However, we present our typing judgements in a slightly different 
manner, i.e. one where the effect is described by a pair of constraints that express 
the update performed by a particular instruction. In a sense the pair together with 
the typed expression can be viewed as a triple in a variant of Hoare logic. The con- 
straints we use to express the type information for an object are approximations of 
the actual types by the matching constraints similar to the ones in [BB99]. 
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This paper is structured as follows. The language in which we model the script- 
ing languages is presented in Section[2] The type system is presented in Section[3] 
Its properties are demonstrated in Section [4] At the end we present related work in 
Section |5] and conclude in Section |6] 

2 Model language and its semantics 

The syntax of expressions we work with is presented in Fig [T] The figure presents 
not only the raw syntax of programs, but also the syntax of evaluation contexts that 
represent ifnormation on the particular point in the program the semantical reduc- 
tion rules elaborate. Moreover, we present here the full syntax of the expressions 
that may show up in the evolution of the expression being reduced. This is reflected 
by the fact that we permit locations to occur in the expressions while the intent is 
they are not directly visible in programs in the source form. 

Definition 2.1 (Types) The type information associated with an expression of the 
language we consider here is combined of two items. One is a representation of 
the actual type and the second is the constraint expression which approximates 
the shape of the type. These components are generated with help of the following 
grammar: 

t b ::= c\ X | 4,1 V4,2 | [ti,...,t„;*i] => [*n+i;*a] 
t ::= t b | ti V£ 2 | 1 
t r ::= {Ut} | {} 
* ::= Jf<#i n *|0 

where c is a type constant from Consty, X £ Vt is a type variable. The set Types is 
the set of elements generated from t, the set Types b is the set of elements generated 
from t b , the set Types r is the set of elements generated from t r , and the set Constr 
is the set of elements generated from fy. 

The set of objects O is the set of partial functions from identifiers to values. 
The set of stores H is the set of finite partial functions from the set of locations to 
the set of objects. The set of evaluation contexts EC is the set of sequences of basic 
evaluation contexts as presented in Figure [T] The set of expressions EX is the set 
of expressions as given in Figure [T] The semantics is defined by the relation ~> 
which relates triples (a, E,e) G H x EC x EX. Let s be a (partial) function we 
write s[x/v] to denote function such that s[x/v](x) = v and s[x/v](y) = s(y) for 
y ^ x and y G dom(s). 

When an evaluation context is a sequence Ei, E2, ■ ■ ■ , E n , we write it as 



E 1 (E 2 (...E n (.}...}}. 
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identifiers 

labels 

locations 



n 



x 



. . . (identifiers). . . 
. . . (identifiers). . . 



constants 
function value 
values 
objects 
fields list 

function expression 
expressions 



c 




op n (ei, • • • ,e n ) 

if (ei) then e2 else 

ifhasattr (x, a) then e\ else e2 

break n e \ n.t {e} 

new I x\.X2 = v I X1.X2 



Vffa, • • • ,Vi-i,E,e i+1 , • • • ,e n ) 
op n (vi, ■■■ , Vi-i, E, e i+ i, ■■■ ,e n ) 
if (E) then e2 else e3 
break n E 
n.t {E} 



basic evaluation con 



E ::= • I let x = E in e 



texts 



stores 



(7 



(Z,o)(7 



Figure 1 : Syntax of Am 
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(Let-Enter) a, E(\et x = e\ in e 2 ) ~> a, (let x = (ei) in e 2 ) 
(Let) cr, E(\et x = (v) in e) ~> cr, £?(e[a:/u]) 

(Op-Enter) cr, S(op„(ei, • • • , e fe )) ~> 

^CT,^(op n ((ei), • • • ,e fc )) 
(Op-Prop) a,E(op„(vi, ■ ■ ■ , Vi-i, (vi), e i+1 , ■ ■ ■ ,efe))~» 

^a,£;(op n (t)i,--- (e i+ i),--- ,w fe )) 

(Op-Back) cr, E(opn{vi, ■■■ , (v k ))) ~> 
a,E(op n (vi, ■ ■ ■ ,v k )} 
(Op-Eval) <T,E(op n {v l7 - ■ ■ ,v k )) ^ a,E(5 n (op n ,v 1 , - ■ ■ ,v k )) 

(/3-Enter) cr, £(func(a;i, • • • ,a: n ).i {e}(ei, • • • ,e fc ))~> 

^ cr, £(func(:ri, • • • , x„)i {e}((ei>, • • • , e fe )) 

(/3-Prop) cr, ^(func(xi, • • • ,a: n ).t {e}(«i, • • • (^),e m , • • • ,e„)) 

^<7,-E(func(a;i, • • • ,x n ).t {e}(vi, ■ ■ ■ ,v l ^ 1 ,v l , (e i+1 ), ■ ■ ■ ,e„)) 

((3v) cr, E{func(x!, ■■■ ,x n ).t {e}(ui, • • • , (u fc ))) 

cr,i?(e [xi/v 1 , ■ ■ ■ ,x n /v n }) 

(If-Enter) cr, E(\f (ei) then e2 else 63) ~> cr, E(\f ((ei)) then e 2 else 63) 
(If-True) cr, £(if ((true)) then e 2 else e 3 ) ~> cr, £(e 2 ) 
(If-False) cr, i?(if ((false)) then e 2 else e 3 ) ~» cr, -E(e 3 ) 

(Ifhtr-True) cr, £?(ifhasattr (Z, a) then ei else e 2 ) ~> cr, £7(ei) 

when a € dom(cr(Z)) 
(Ifhtr-False) cr, ^(ifhasattr (Z,a) then ei else e 2 ) ~> cr, £?(e 2 ) 

when a ^ dom(cr(Z)) 

(Brk-Enter) cr, i?(n.t {e}) ~> cr, E(n.t {(e)}) 
(Brk-P) a.E^n.t {E 2 (break n«)}) ~» <J,Ei(v), 

when n does not occur as label in i£ 2 
(Lbl-Pop) cr, E(n.t {(v)}) ~> cr, £(v) 

(New) cr, £(new) ^> (i, 0)cr, £(Z) Z fresh 

(SetRef) a,E(l.f = v) ~» tr[//o-(Z)[//t)]], £(u) 
(Deref) a, E(l.f) ^ a, E(a(l)(f)) 
when / € dom(cr(Z)) 



Figure 2: Semantic rules of Am 
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When the relation holds between triples (a, E, e), (a', E', e') we write the relation 
as a, E(e) a', E'(e'). The precise semantical rules are given in Figure|2] 

We do not model inheritance and multiple inheritance of the scripting lan- 
guages. We assume that this can be viewed as a notational shortcut for direct 
presentation of objects and therefore we cannot model all features of the class 
models (e.g. the method updates in classes in Python). 

Constructs of the language The language we propose has object-oriented fea- 
tures such as object creation (new), field reference (the dot notation 2:1.2:2), and 
field modification (2:1.2:2 = v). In addition we have object introspetion operation 
available through ifhasattr (•, •) then • else • construct. The flow of information 
is controlled by let x = e\ in e2 expression that in addition to creation of a local 
variable x makes possible to execute e\ and e2 in sequence. The traditional split of 
control flow depending on a computed condition is realised by if (•) then • else •. 
The exceptional flow can be realised by our labelled instructions combined with 
break statements. At last loops can be organised by recursively defined functions. 

Notably we use types in labelled instructions and in function declarations. 
These types can in fact be omitted since they do not play part in the respective 
reduction rules. The possible errors that may result by execution of an operation 
on a value that the operation is not prepared to take are present in our system 
through appropriate definition of S n that can check the types of the values supplied 
in the arguments. 

3 The type system 

Typing judgements are of the form Vl/i; T; E h e : tf,; ^f 2 where F is an environment 
(i.e. mapping from variables to tb), E is a mapping from locations to type variables 
Vt, *i for % = 1, 2 is a set of constraints of the form X <# t. 

The intended meaning of such a judgment is: evaluating e in the environment 
r with types of locations that match the mapping E and with the store satisfying 
\&i leads to a value of type tb and store satisfying Hf 2 . 

Record update The information about the record being updated is represented 
by a constraint on a variable X. The rule for record update comes in two variants, 
depending on whether the constraint mentions the field being updated. 

$i;r;Sh x : X;Vi 

*i;T;E he: t 2 ;^ 2 ,X <# {a : t' 2 ,TVs} 

(update-old) 

*i;T;E \- x.a = e: t 2 ;^2,X <# {a :t 2 ,l: s} 
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If (we know that) the record contains the field a that is to be updated, we forget the 
old value, hence its type (t' 2 ) is ignored; the store after the update reflects the new 
value of a. 

*i;T;S h x : X;^! 

*i;r;She:t 2 ;* 2 ,^<#{N a 

=- (update-fresh) 

h x.a = e : t 2 ;^ 2 ,X <# {a :t 2 ,l: s} 

otherwise the constraint for X is amended with information about the new value 
of a. 



Record access We can access a field a provided the constraint on the record 
guarantees that it has the field a and it is of a definite type (it cannot be _L). 

hu ^ 3 X <# {a : u,TTt} 

T „ „ „ , =— (access) 

f;r,i:I;Ehi.o:u;f 

A type is definite (h u) if it is a type constant, type variable, function type or a 
disjunction of definite types. This is defined inductively as follows: 



he hi 
H h ht 2 



\-h vt 2 h [ti,...,t n ;%] =► [«;*2] 



Conditional instruction The basic way to split the processing depending on 
some value is to use a conditional instruction. This instruction is typed in our 
system in the following way. 



^;T;S h gi : bool-^x $i;r;She 2 :«;$2 $i;r;Ehe 3 :n;f 2 (if) 
^;T;S h if (ei) then e 2 else e 3 : n; ^ 2 ' 

The typing of the branches need to be typable into the same type. However, 
the constraints in each of them can be in principle different. Therefore we need a 
rule to weaken the constraint so that they result in the same set. For this we need 
an operation that merges type constraint from two branches. This is defined in the 
following way. 

• X <# {TTt} y X <# {FTF} = * w X <# {177} w {FTP} 

• * y = ^ 
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• = * 

• {l : t , TTt} a {l : t' Q ,T7j?} = {l : t V t' ,WT¥} where {F7F} = 

{T7t} y {FTF} 

• {} w {F77 7 } = {F : f v 1} 

• {F~iT} w {} = {F : f v 1} 

This combination of two sets of constraints need to be incorporated into type 
derivation and this can be done using the following weakening rule. 

*;r:Ehe:t;$! , , 

- — = , - — - — (weaken-l+1) 

*;r;Ehe:f;*iW$ 2 

Object structure introspection Dynamic languages split the processing not only 
depending on some condition defined in terms of the actual values, but also depend- 
ing on types of expressions. Therefore, we introduce the construct that performs 
appropriate check and provide a typing rule that handles it. 

V[X <- {a}];r,s : X;S h e x : t;^ 2 r, x : X; E h e 2 : t; % 
T, x : X; S h ifhasattr (ar, a) then ei else e 2 : t; * 2 W *' 2 

The typing rule must update the typing information available in the branches of 
the instruction. Type information in one branch takes as granted that the attribute 
a is present. We need not pass the information that the attribute a is missing in the 
other branch since the case that the actual value does not have the field a must be 
expressed in the type description by an alternative with _L. 

• <#t)[X <- {a}} = V,X <# (t[X <- {a}]), 

• {a : ti V ■ ■ ■ V t n ,l : u}[X 4- {a}] = {a : t h V • • • V t ik ,l : u] where 
{t h ,. . .,t ik } = {U | U ^ _L andti G {ti, . . . ,t n }}. 

We assume that base types are implemented so that they have a distinguished 
field which makes possible to check for base type with ifhasattr (?, ?) then ? else ?. 

Variable and location access The information about a type of a variable is 
recorded in the type environment so we use it when a variable is referred in an 
expression. 

- — =n — (v-access) 
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Similarly, the information about locations is stored in the location environment 
£ and we exploit it in an analogous way. 

- — = , : — , — (1-access) 

*;r;S,Z : t h / : * 

Function definition and call Whenever we want to type a function definition 
we must rely on the type annotation that is associated with the function. We have 
to add the type decoration to functions since they can be used in a recursive way. 
The inference of a type in such circumstances must rely on some kind of a fixpoint 
computation which is a difficult task. We assume here that the type is given in the 
typechecking procedure either by hand with help of programmer or by some kind 
of automatic type inference algorithm. 

The type we obtain for a function definition is just the type that is explicitly 
given in the function. However, we have to check in addition that the body of the 
function indeed obeys the declared type. Therefore, we assume that the formal 
parameters have the types expressed in the precondition of the function type and 
obey the constraints noted in the constraint set from the same precondition. We 
expect then that the resulting type is equal to the one in the postcondition of the 
type and the constraints match the constraints in the postcondition. It is worth 
noting that the constraints in the precondition and postcondition should take into 
account not only the formal parameters, but also the global variables that are visible 
in the function body. 

Notably, we type the function body so that the typing does not interfere with 
the typing of the function definition. This reflects the dynamic character of the 
language. In particular the running time type of a global variable may differ at the 
function definition point from the expected one so that the typing is impossible at 
that particular moment. However, the situation may be different at the execution 
site. Therefore, we defer the check of the compatibility of global variables to the 
function call site. 

t = [ti,...,*„; *i] =► [u;* 2 ] 

*i; T, xi : h, . . . , x n ■ t n ; S h e : u; ^2 

(fdecl) 

*; T; £ h func(xi, • • • , x n ).t {e} : t; * 

In case a real application of a function expression is made to arguments we 
have to check that the application indeed does not lead to type error in this case. 
Therefore, the typing rule for application must check that the type information 
for global variables at the call site (i.e. after all actual parameters of the call are 
elaborated) is in accordance with the type information available in the functional 
type. This is checked with the relation -< c . 
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Definition 3.1 (^ c ) The rules that operate on constraint sets are as follows. 

g < c ^' t < c t' 

^ < c % <#t ^ c V',X <#t' 

They reduce the problem to the one on record types where the relation is defined 
as follows. 

t < c t {Ut}< c {} {a:u,T7t}± c {T7t} 

u < c v! 
{a : u,l : t} < c {a : v! \l : t} 

U -< C U U\ -< c U\ V U2 U2 ^ c U\ V U2 

Ul u 'l U2 Ific U*2 
til V«2 u' 2 V u[ 

Proposition 3.2 The relation ^ c is reflexive and transitive. 

Proposition 3.3 For any constraint sets \I>i, ^2 we have f 1 ^ $1 y x $>2- 

Execution of a function body causes changes of values held in global variables. 
Such changes may give rise to changes in the types. This must by reflected and the 
type information must be updated accordingly. Therefore, we need an operation of 
such an update. 

Definition 3.4 (type information update «-^) For two sets of constraints Vl/i, ^2 
we define inductively the set of constraints ^1 ^2, in words constraints \&i 
updated with ^2, as follows. 

• ^ = 

• x <# t ^ x <# t' = (* ^ y'),x <# t', 

• ^ ^ X <# t! = (* ^ #')> ^ < # *' x dom(tf). 

It is important to observe that the update preserves at least the type information 
that is present in the constraint with which we make the update. 

Lemma 3.5 For any constraint sets ^1 , ^2, 

^2 #1 <^ ^2 



3 THE TYPE SYSTEM 



11 



We can now present the rule for function application. This rule elaborates 
first all the expressions in the actual parameters and updates the constraints so 
that their side effects are taken into account and then weakens the result to match 
the constraints for the input part of the function type. Then the resulting set of 
constraint is just the set of constraints after the last argument updated with the 
constraint information contained in the result type of the function. 

*i; T; E h : tf, for i = 1, . . . , n # n+ i < c 

* i; r;Eh e/ t n ;%] => [u;tf 2 ];*i /£ ^ 

, (rapp) 

* 1 ;r;Ehe / (^ 1 ,...,Ar n ) :u;V n+1 ^% 



Control flow with break instructions The language we propose includes non- 
local control flow instructions that may be used to simulate exceptions or jumps 
out of loops (recursive calls in our case). The labelled instruction resembles a 
call to an anonymous function with no parameters. We only have to remember 
type information that we want to achieve as the result of the execution. Note that 
the prospective break instructions can reside inside of a recursive function call. 
Therefore, we cannot assume that the type we give here explicitely is a result of a 
finitary collecting of a non-local typing information from all the break statements 
inside e. 

tt;r,n:[;0] [*; ggjj E h e : t; % %^ c ^ 2 

*;r;Ehn.[;0] => [t; V 2 ]{e} : t; * 2 U ° 

In case we encounter brea k instruction we have to check that the expression the 
value of which it given as the result indeed obeys the expected result type of the 
labelled instruction surrounding the break. 

tt;I>:[;0] [*; tt 2 ]; E h e : t; % %±c*2 

* ; r,n:[;0] => [t;* 2 ];Sr-breakne:t / ;* / 



Let-expression The let expression is our language statement that does the in- 
struction sequencing operation. Therefore, we have to compute the constraints for 
the first step, then for the second one and at last combine them together as in the 
logical cut rule that forgets the middle formula. 

j^JYEJ-ei :ti;tt 2 ^ 2 ; T, x : h; E h e : t; ^ 3 
^i;T;E h letx = ei in e : t;*3 
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Object creation The object creation rule should just introduce information that a 
new object is created. This is expressed by the fact the set of constraints is extended 
with information on an object that has no known to the type system fields. 

X fresh , , 

(new) 



$ ; r ; Sh new : X;X <# 

Disjunction We also add a rule to weaken the assumptions about an expression. 
This is primarily necessary to obtain the subject reduction property. In case an if 
instruction is reduced to one of its branches the type system infers only information 
from one of the branches and the information from the other one must be added 
artificially. 

*i;r;She:^;*2 z = lor2 

^T^he^Vt^ (Weaken " V) 

4 Properties of the type system 

Soundness and subject reduction need to take the store into account. Hence we 
need to express the fact that a store instance satisfies certain constraints: 

a; £ |= # 

where a is a store, £ a mapping between locations and types, and ^ a set of 
constraints of the form X <# t. 

Definition 4.1 (|=) If c is a constant of type t c : 

a; £ |= c : t c 

For function values: 

^;0;cr h func(x).t{e} : t;V a; £ |= * 



a; £ |= func(x).t{e} : t 
a;£ M 



(\=fun) 



If I is a location: 



a; £ |= * a, £ |= v : t 



a[l/{arv,yTs}}; £(/ : X) \= X <# {a : t}, * 



(1= obj) 
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in particular, for every object o: 

a(l/o);E(l : X) \= X <# {} 



For any ^, 



For any h,t 2 , 



a; £ |= * 1+1 * 
cr; £ |= v : t 



(1= v) 
cr;S |= v : ti Vi 2 

Lemma 4.2 (soundness of ^ c ) For any a, £ and constraint sets Vl/i, ^2, i/c, £ |= 

*i and *i ^ c *2 a, £ |= ^ 

Proof: 

It is sufficient to prove that if a, £ |= X <# 01 and 01 ^ c 02 then a,T> \= X <# 02. 
We proceed first by induction on the derivation of |=. The only nontrivial rules are 

(|= obj) — again, the only (marginally) nontrivial case is when o\ < c 02 was derived 
via the disjunction rule: 



{/ : t} ± c {I : t'} 



{a : u, I : t} < c {a : u V v! , I : t'} 

In this case we can derive cr, £ |= X <# 02 by inserting (|= V) before the 
"a : u" premise of the final (|= obj) rule in the original derivation. 

(|= l±J) — we have cr, £ |= X <# o\, 02 = o\ l±J o' , 02 -< c 03 and need to prove 
cr, £ |= X <# 03, which can be done by induction on the definition of 

02 03. 

Lemma 4.3 If 



cr;£(Z : X) |= X <# {a : t; f : s}, V 
and \- t (i.e. t contains no _Lj, then 

(i) a (I) (a) is defined 

(ii) cr;£ |= a{l)(a) : t 
(Hi) cr; £ |= 
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Proof: 

By induction on the derivation of a; S(Z : X) \= X <# {a : t; f : s}. 

If the last rule is (|= obj) then the thesis follows immediately. On the other 
hand, if the last rule is (|= l±l), we have 

X <# {a : t,f: u},*' = *i W * 2 
(1= U) 

By the definition of l±l, one of the following holds: 

(a) = X <# {a : t,f : u}, X dom(^ 2 ) 

(b) m 2 = X <#{a: t,JTu}, %, X cfom(*i) 

(c) = X <# {17^}, ^, * 2 = X <# {FT^ 7 }, *' 2 

If (a) or (b) holds, the thesis follows directly from the induction hypothesis. 

In the (c) case, by the assumption that h t, we have a £ /, a G /'as well as 
t = tiVt 2 with h ti and h i 2 . 

Moreover, either 

a;S|=X<#{a:t 1 ,/T^},^ , 1 

or 

C T;S|=X<#{a:t 2 ,7 r ^7},^ / i 
Then by the induction hypothesis a(l)(a) is defined, and 

cr; £ |= a(l)(a) : tj 
for appropriate i. Thus by the rule (|= V) we have 

a;S |= a(l)(a) : ti V* 2 
which completes the proof. □ 

Lemma 4.4 (value completeness) For any a, S, T, \I> and va/we v if a,T, |= ^ 
and a, £ |= t> : t tfien $;f;SI-i):f;$ 
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Proof: 

By induction on the derivation of a, E |= v : t. For the constant and function rules, 
the thesis follows directly. 

On the other hand if the last rule used was 

cr;E |= v : ti Vt 2 

then by the induction hypothesis h » : tf, hence ^; T; E h v : t\ V 

Lemma 4.5 (Progress) //$i;r;She:t;$2 ««d a; E |= e : t; f/ien e/f/z<?r e 
is a value, or 

a,e^> a' , e 

Proof: 

The only expressions which may get stuck are record access (in case of lack of a 
field) and function application (in case of arity mismatch). Reducibility of record 
access follows from the Lemma 1431 

Lemma 4.6 (value stability) If v is a value and 

$i;Shu:t; ^ 2 

then ^ c 

Moreover, for any ^ we have $;Shi):t;$ 
Proof: 

By induction on the derivation. The thesis follows directly for axioms and the 
function definition. For the disjunction rule use the induction hypothesis. For the 



ttJ rule the thesis follows from Proposition 3.3 



Since v is a value, no other rules can be used in the derivation. 
Lemma 4.7 (weakening) If^i; T; E I- e : t; * 2 and T C T', E C E' then 

*i;r;E'he:t;* 2 

Proof: 

By routine induction on derivation. 

Lemma 4.8 (subject reduction) Reduction preserves typings, i.e. if 

*i;r;She:t;$ 2 
cr; E |= 
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a,E(e) ~» cr',£(e') 
then there exist V I // smc/j ?/zatf EC? ant/ 

V;r;She':t;$2 
a'; S' |= ^' 

Moreover ifa = a' then the thesis holds for £' = £ a«<i VP' = VP. 
Proof: 

By induction on the derivation. We now consider several cases depending on the 
last rule used 



Case e = new: 



If <j;£ |=*i then 



* ; r;E h new : X;X <# {},\? 



: X) |=X <#{},* 



Case e = La: 



hw ^ 9 X <# {a : u, f : t} 
* ; r;I:XEh La : u:V 



We have a, E (l.x) ~> cr, o"(/)(a). Since a; / : X, £ |= then by Lemma 4.3 c(Z) 
has field a of type u: 

a; £ |= cr(/)(a) : u 



Hence by Lemma 4.4 



$;r ; l:I,Sh <r(Z)(a) : u; \t 



Case e = if (ei) then e 2 else 63: 

$>;T; £ h ei : 600/; ^1 $1; T; S h e2 : u; $2 *i; T; £ h e 3 : it; * 2 

if (ei) then e 2 else e 3 : u; \& 2 

If ei is a value then a, E (e) reduces to a, E (e') where e' is either e 2 or e^. In 
both cases we have 

$i;r;She':i;$ 2 
a'; £ |= \t 2 

Otherwise, cr, i£ (ei) ~> cr', £7 (e^). By induction hypothesis, there are £', Vt' 
such that 
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a'; £' |= ^' 

By the typing rule for if and Lemma |4~7j we have 

T; E' h if (ei) then e 2 else e 3 : t; * 2 

Case e = func(xi, • • • ,x n ).t {e b }(vi, ■■■ ,v k ) : 

^f[;T,x : t\ E h e b : u; V 2 

^i;r;EI-func(f).t{e 6 } => [u;* 2 ];*i 

^; T; E h Ni : U; for i = 1, . . . , n ^ c 

r; E h func(f).t {e 6 }(iT) : «; * n+ i ^ *' 2 
For simplicity consider case when n = 1 : 



*i;r,a; : ti; E h e fe : u; % 
*i;r;Shfunc(x)i{e fe } : [ti;^] =^ [«;*' 2 ];*i 



*i;r;Eht;i:ii;* 2 

*2 



$i;f;Sh func(x).* {e fe }(u) : u; ^ 2 ^ 



We have 



a, E (func(x).t {e b }(«)) ~» a, £ ((e b [x/u])) 
Consider an occurrence of a variable axiom for x in the type derivation for e b : 



By the stability lemma (4.6 1, ^ x ',^' l~~ v : ti;SSf x . Hence by replacing all such 
occurrences by appropriate type derivations for v, we get 

$[;T,x : ii;£ h e 6 [x/u] : u; * 2 



By the Lemma 4.6 < c \I / 2 , and $ 2 ^ c vt^ is the side condition of the 
application. Hence by transitivity of -< c we have ^ c ^ . 



By Lemma 3.5 we have < c ^2 ^ hence 

*i; T,x : t x ; E h e 6 [x/i;] : it; ^ 2 ^ * 2 
. Which was to be proved. 
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Structural rules (tt), V) If the last rule used is 

*i;r;She:ti;* 2 



*i;T;E h e : h Vt 2 ;f 2 



then by the induction hypothesis the thesis holds for tt, hence by reapplying the 
disjunction rule also for t\ V i 2 . 
If the last rule used is 

$;r;Ehe:^ 2 



*; T; E h e : t; $ 2 tt) * 3 
Then by the induction hypothesis 

*';r;Ehe':t;$ 2 
a'; E' |= 

And we can get the thesis by applying the tt) rule. 
Theorem 4.9 (soundness) If *i; T; E r- |-E(e)| : i; ^2 a«<i 

a; E |= *i 

f/ien either a, E(e) has an infinite reduction path, or it reduces to a value v, 
i.e. there exist a' , E' and value v such that 

a, E(e) a , v 

and 

ct';E' : i,* 2 - 

Proof: 



By the progress lemma (4.5 1, the reduction can stop only at a value. Required 
properties of the final value and state follow from lemmas [478] (by induction on the 



lreduction length) and 4.6 



5 Related work 

The starting point of our research is the paper by Guha et al BGSK111 where a type 
system for scripting languages is presented. The type system there does not address 
the types of objects and only infers the typing information concerning base types 
(including special type of references to take into account object in a very simple 
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way). We provide here a type system which in addition to the one by Guha et al 
can infer meaningful typing information for objects. 

In addition, the paper by Guha et al relies on runtime tags which are present in 
the semantics of dynamicly typed languages such as JavaScript. The checks over 
runtime type tags can be viewed as asserts that check if the particular value is of 
an expected type. This primitive has, however, one disadvantage. Namely, it does 
not reflect the split in the control flow that makes possible to use particular type. 
Still, the scripting languages have operators that check for the actual running time 
type of a value (e.g. typeof function and in operator in JavaScript, or hasattr, 
getattr, and getattr_Static in Python). We consider it more natural to rely on these 
operators instead of the tagchecks. 

Our typing framework works in a fashion such that, in principle, all the typing 
information should be present. This scenario is not realistic when the expectations 
of the scripting languages programmers are taken into account. Each real effort 
to bring static information into the program development here must consider what 
was explicated in ITWEF + 09 1 and realised in a scpecific way in Thorn scripting lan- 
guage ||BFN + 09l and led to interesting type architecture ||WNL+ 1 Oal IWNL+ 1 Obi . 

6 Conclusions and future work 

The type system presented in this paper gives an expressible framework for typing 
objects in dynamic languages such as Python or JavaScript. It follows the general 
view of type-and-effect systems where running time program property must be 
expressed as a dynamical change. We express this change by means of Hoare- 
like triples that describe the structure of relevant objects before an expression is 
executed and after the execution. 

The type system is presented in a fashion similar to Church-style. The nec- 
essary typing information must be provided by a programmer. We work now on 
helpful heuristics that will infer most of the type information to make the annota- 
tional effort of a programmer minimal and on the way a system with types can be 
integrated to real program development in scripting languages. 
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